Under our consistency guarantee, we can't make data from new checkpoints visible if there are local changes that haven't been uploaded yet. Our current implementation for this case (recognizable by ready = false) was to simply do nothing. That's not unreasonable: After all, the pending local changes are supposed to be uploaded eventually, which should trigger new checkpoint messages that we'd then apply.

However, there is a potential race condition when a pending upload is currently in progress. While the connector is uploading changes (and before finishing), some data may already be uploaded to the database, triggering the sync service to send new checkpoints. These checkpoints would be entirely ignored, because we're already uploading data and there is no subsequent upload to trigger another one.

To fix that issue, this PR improves the checkpoint handling logic. If we get a checkpoint complete message that didn't apply because of local data or a write_checkpoint mismatch, and we're currently in the process of uploading changes or waiting for a write-checkpoint2.json request, then await that before trying the same checkpoint again. Either,

• the same checkpoint message applies now (in case it was emitted before the connector completes or the write-checkpoint2.json returns). Or,
• we can expect another checkpoint to come up soon (since we've waited for the response and the old one didn't work). Doing nothing is the correct behavior here.